[レポート] GPSTEC334: AWSにおける分散型 Ethereum アプリ（DApp）の設計 #reinvent

スピーカー

• Rafael Lopes
  • Senior Partner Solutions Architect
• Carl Youngblood
  • Senior Blockchain SA, Amazon Web Services

セッション概要

従来のデプロイパラダイムに反するという評判にもかかわらず、ブロックチェーンアプリケーションでさえ信頼できるインフラストラクチャを必要とし、さまざまなレイヤーでいくつかの一般的な DevOps パターンを利用します。実際、DApps は、ユーザーエクスペリエンスを損なうことなく、または分散化を犠牲にすることなく、高度な可用性とスケーラビリティを維持するために私たちの工夫を必要とする課題をエンジニアに提示します。このチョークトークでは、AWS で Ethereum DApp を設計および開発するプロセスについて説明します。まず、アーキテクチャの概要から、ライブデモを使用して開発および展開プロセスを説明します。独自のブロックチェーン DApp を開始するための堅実な概念基盤が得られます。

レポート

デモ

• まずはアプリケーションのデモから
• さまざまなエンティティがブロックチェーンに参加できる方法を示すシンプルなアプリ
  • アンケートを作成し、それらのアンケートに応答して投票する簡単なシステム

なぜ DApps なのか

• React などの SPA でも同じことができると思うかもしれない
• ブロックチェーンによるいくつかのパライダイム
  • データが個々のダウンする可能性があるサーバに保存されていないこと
• インターネットが最初に公開されたときと同じよう
  • TCPIP を話すことができる環境があれば誰でも参加できた
  • Ethereum や Bitcoin などパブリックブロックチェーンは、適切なプロトコルを話すことができればネットワークに参加できる
• あらゆる種類のミッションクリティカルなワークフローまたはプロセスを特定のインフラストラクチャで必ずしも実行されていない分散ピアセットによってサービスを提供できる
• その利点にはいくつかの課題がある
  • これらのパブリックチェーンのすべてのノードは基本的にデータを複製する必要があり、トランザクションレートは非常に低い
  • ネットワーク全体で約15トランザクション/秒のトランザクションレート
  • 現在、これらの非常に難しいスケーリングの課題に取り組んでいる
• 多くの企業は、ブロックチェーンノードを実行するための信頼性の高いインフラストラクチャを求めていますが、難しい問題やコンピューターサイエンスが解決するのを待つことはできない
  • したがって、今日お見せするのはデプロイのための可用性の高いレシピのセット
• いくつかの注目する DApps がある
  • CryptoKitties
  • MakerDAO などの 分散型金融の DeFi で起きていることは本当にエキサイティング
  • Sovrin ID
  • decentraland.org
  • 分散型組織

Ethereum のキーコンセプト

• 最初のブロックチェーンはビットコインといわれている
• 基本的に人々はどこにいても金銭的価値を、ある当事者から別の当事者に移すことができる
• 第2世代のブロックチェーン。台帳だけでなく、任意のコンピュータ命令を台帳に保存する機能
  • そのため、Ethereum は本質的にグローバルコンピューターであり、ネットワーク内の各クライアントまたは各ノードは、オプションを実行する完全な仮想マシン
  • Ethereum の場合、これらの命令は理論ネットワークのすべてのノードで実行されている
  • この仮想マシンで実行され、各ノードはそれらのトランザクションがネットワークの残りの部分で有効で伝播されることを確認している
• これらの命令は実行するのに時間とコンピュータの能力を要する高価なコードが含まれている可能性がある
  • gas と呼ばれるものを使用して、ネットワークにトランザクションを送信するユーザーは、ネットワーク上で使用している時間に対して適切な料金を支払う必要がある
  • 暴走プロセスを送信した場合、そのプロセスを実行するまでそれを実現するために資金を使い果たす
  • 完全に稼働する前にアプリをテストネットにデプロイして、お金を使い始める前に想定が安全であることを確認することもできる

Q.　「gas はユーザーが支払うのか？」

A. 「良い質問なので掘り下げます。ユーザーに代わって gas を支払うことも可能です。これはブロックチェーンの採用の大きな障壁の1つです。アプリケーションと対話できるようにするためだけにウォレットを開いてポップアップする必要があるという考えです。一般的な用語ではメタトランザクションと言います。メタトランザクションについては、いくつかの興味深いプロジェクトがいくつかあります。

• 最後に指摘したいのは、彼らがプライバシーを保証しない場合、あなたがブロックチェーンに置いたものはブロックチェーンの他の参加者が読むことができる可能性があるということ
  • 現在、それに取り組んでおり、企業の理論を強化する Ethereum アライアンスは、プライバシー機能を仕様に追加している
  • Amazon Managed Blockchain のようなブロックチェーンサービスでもプライバシー機能も提供
  • 今日話しているのは Amazon Managed Blockchain で利用できる種類の機能ではない

Q. 「プライバシーはセキュリティや暗号化と同じではありませんか？セキュリティと暗号化、プライバシー、およびそれを行うさまざまな側面について考えてみてください。パリのプライバシーは保証されておらず、多くの場合、セクションは暗号化されていませんか？」

A. 「ええ、つまり、ある程度はそうです、もしあなたが暗号化したいブロックチェーンに秘密情報を入れようとするなら、プライバシー機能が組み込まれたいくつかのパブリックおよびプライベートのブロックチェーンがあります。」

Everything fails all the time.

• Web サービスクラウドコンピューティングの周りにあり、すべてが常に失敗する
• つまり、これらの接続は攻撃者に直面することを意味する
• この分散アプリケーションは自由なネットワーク上の情報を複製するのに非常に成功している。
  • あらゆる種類のフロントエンドをデプロイするときは必ず高い可用性が必要

デモのアーキテクチャについて

• 複数の AZ を正しく活用している
  • 複数の AZ で ECS コンテナを使用
• 顧客にこれらの高可用性を実装する方法を選択するいくつかのオプションがある
• トランザクションが正しくダウンしないようにしたいので、実際に何がネットワークに送信されるデータの耐久性に非常に優れた能力を与える
• 別のサービスを使用している場合は、考慮すべき点がいくつかある
  • Lambda、SQS のようにリージョンスコープレベルを使用している場合、基本的には高可用性にあまり関心がない
• AZ はリージョン内のデータセンターのクラスター。それらは互いに数十キロメートル離れた場所に物理的に分離されている
  • 複数の AZ に同時に影響を与える自然災害のようなもののために、物理的に数十キロ離れてる
  • 災害や地震などを考慮しているなら、AZを数百または数千マイル離れた場所に配置しないのはなぜか？
  • DynamoDB, Lambda, SQS, SNS, Blockchain など、いくつかのリージョンスコープレベルでは多くの場合、データレプリケーションが行われている
  • 相互に動作するのに十分ではないレイテンシーが発生しする。そのため、AZ 間に低遅延の高速リンクがあり、冗長電源とファイバー接続がある
  • AZ はリージョン内で分離されており、各 AWS リージョンには少なくとも2つの AZ がある

Q. 「i3 インスタンスを使うのはなぜですか？」

A. 「ブロックチェーンノードは実際に I/O を集中的に使用する傾向があります。そのため、ストレージ最適化されたインスタンスを使用しています。このためトランザクションの多くは NVMe スタイルのSSDで非常に高速な SSD を通過し多くの I/O スループットをもたらしました」

• 課題の1つは、これらのノードを起動するときです。通常、最初からノードを開始するだけなら数時間、場合によっては数日かかる
  • 代わりに行っているのは、アップデータープロセスと呼ばれるこの特別なプロセス。このプロセスは4時間ごとに実行され、基本的にノードからの接続を切断します。
  • そのため、ブロックチェーン状態は初期状態ではなく、ブロックチェーン状態の内容を S3 バケットにコピーするのに数分かかる
  • これはブロックチェーンの状態を複製する非常に手頃な方法
  • それには数分かかり、新しいノードが起動するたびに、実際にこのバケットから状態をコピーします。そして 数分後に新しいインスタンスが入ってくる

Q. 「S3 の代わりに EFS ではだめか？」

A. 「S3 のほうが費用対効果が高い。ソリューションアーキテクトとしての私たちの目標の一部は、知っていることのくだらない部分を最適化し、最も費用対効果の高い方法を見つけることです。そうすることができるときはいつでも、私たちは幸せです。それは合格または不合格ではなく、特定のトピックに応じて、より最適化された、最適化されていない。パフォーマンスがより最適化されたインフラストラクチャは、コストがあまり最適化されていない場合がある。」

Q. 「障害モードまたは潜在的な障害モードに対して、ノードを新しいバージョンにアップグレードするより良い方法は？」

A.　「本当に良い質問です。そのため、現時点では、このソリューションを展開する際に、失われているクライアントのバージョンを変更することで基本的に展開しています。これらすべてを実際に更新しているのは、本質的にソリューションを再定義することです。したがって、ロールオーバーアップグレードを見ると、既に準備ができているコードの一種の機能強化になりますが、それを確認するのはそれほど難しくないはずであり、皆さんからもっと多くの考えを聞きたいです。同様に、基本的にあなたがそこでやりたいこと。インストールのために行った問題を管理する1つの潜在的な方法は、リポジトリの異なるブランチを通じて管理される一連のクラスターを持つことです。そして、そのリポジトリへのコミットは何らかの委員会によって管理されており、私は改善者であり、コミットを許可し、コミットが承認されると、本質的にはコミットが特定のセットのバージョンレベルを上げるだけです。」

今回のデモ環境

以下、GitHub に公開されているそうです。

• ecs-rpc-service - A highly-available ethereum node service for Amazon Elastic Container Service

さいごに

DApps アプリ基盤といっても基本的には EC2 や ECS 上で動作するので、AWS の一般的なベストプラクティスを守ることが大事ですね。ノードを追加する際のブロックの同期について S3 に定期的にアップしておくというのは参考になりました。また興味深い DApps がすでにいくつもあるので、ちょっとずつ追っかけてみようかと思います！

以上！大阪オフィスの丸毛（@marumo1981）でした！